#Domino REST API
Posts tagged #Domino REST API · 13 posts
- Domino REST API 1.1.8 Released: Experimental CalDAV/CardDAV, New PIM Endpoints, and Cluster Failover
DRAPI 1.1.8 (2026-09-14) is out. This release brings experimental CalDAV/CardDAV/DXL Extension APIs (off by default), new PIM endpoints for mail attachment lists and calendar profiles, PIM reading mail from a cluster member when the primary is down, and fixes for Keycloak/OIDC key rotation. A few behavior changes are worth noting before you upgrade too — richTextAs defaulting to HTML, qrp/json requiring forms, the calendar-profile rename, and calendar entries needing date/timezone/duration — covered in the body.
2026.09.18 - Domino Attachments over REST: DRAPI and DAS Both Have Attachment Endpoints — the Difference Is Modern vs Legacy
The earlier pieces were about users uploading from a UI; sometimes you move attachments programmatically over REST. Domino has two REST APIs: DRAPI (modern, KEEP) and DAS (legacy, Extension Library). A common misconception is 'DAS is read-only' — not so: DAS has its own dedicated attachment endpoints to create, read, update, and delete. The real difference is modern vs legacy, plus a DAS-specific trap: don't push a whole document with embedded attachment data through create/update (it returns 400) — use the dedicated attachment endpoint. This piece lines up both APIs' endpoints and differences.
2026.09.10 - Put the CA in certstore and Everything Trusts It? DRAPI's Outbound Actually Uses the JVM Truststore, Not certstore
Once a certificate is in certstore.nsf, developers hit two practical questions: how does my service — the Domino REST API especially — serve HTTPS straight from it? And when my own code calls out over HTTPS, does it validate the peer against certstore too? The second answer breaks a common misconception: on one server, certificate trust is actually split across three separate places. Part three of the certstore series, grounded in hands-on testing on Domino 12.0.2, covers DRAPI's keepconfig.d TLSCertStore config, what certstore's trusted roots are really for, and disentangles certstore / Domino Directory / JVM cacerts once and for all.
2026.09.04 - The Domino REST API Before Go-Live: the Security Model, One-Way Rich Text, CORS, and Admin Ports
Series finale. You can authenticate, expose a scope, CRUD, and query; before handing it to real users, a Domino developer must be sure of two things: does it bypass my Readers-field security, and what will bite in production? The answers: DRAPI is layered security (JWT + scope + Domino's own ACL/Readers underneath), so it doesn't leak — but there are real limits (rich text is one-way out, unconfigured fields are unreachable, same-name forms/views are ambiguous), plus CORS and the admin ports to close before going live. Part six (final) of the DRAPI series.
2026.08.24 - Your DQL Is Correct but Returns Nothing? The Form Is Missing a dql Mode
Last part fetched a single document by unid. What you usually want is 'the batch that matches' — all incomplete todos, all customers in a region. DRAPI gives two paths: GET /lists/{view} to read a view/folder, or POST /query to run DQL. DQL even supports parameterized queries (?VAR + variables, injection-safe). But there's a trap that follows from the last part's modes: a form without a dql mode is completely invisible to DQL. This part covers both query paths, pagination, the mode trap, and DQL access control. Part five of the DRAPI series.
2026.08.23 - Creating a Document in the Domino REST API: Why It Needs a Form Field and a dataSource
The door is open (schema + scope); this part does the real work: create/read/update/delete NSF documents over REST. Create is POST /document with a required Form field in the body, and the response @meta carries a unid; read is GET /document/{unid}/{mode}. Every CRUD call carries dataSource — and that value is the scope name you made last part. It also covers two things that give Domino developers pause: why the Form field is required, and what a mode is. Part four of the DRAPI series.
2026.08.22 - Scopes and Schemas in the Domino REST API: How an NSF Becomes REST Endpoints (Exposing Nothing by Default)
Putting an NSF on REST isn't flipping a switch that exposes everything. DRAPI is secure-by-default: you write a schema (a whitelist of which forms, views, folders, agents, and fields go out), then create a scope (the REST mapping that activates it). A scope's name is the very name the JWT scopes claim recognizes from the last part — and underneath, Domino's ACL and Readers fields still apply. This piece separates schema from scope. Part three of the DRAPI series.
2026.08.21 - Getting 401s from the Domino REST API? Understand Its JWT Authentication and Scopes First
Almost every DRAPI call has to prove who you are. It doesn't use classic session/LTPA — it uses a JWT bearer token: POST to /api/v1/auth with Domino credentials for a token, then send it in the Authorization header on every request. This piece covers logging in for a token, what the scopes/aud claims control, where tokens come from (Domino-signed JWT, external OIDC, idpcat.nsf), and traps like the signing key changing on restart. Part two of the DRAPI series.
2026.08.20 - Getting Started with the Domino REST API: Turn NSF Data into Endpoints Any Language Can Call
You want a modern front end, a Python service, or a Power Automate flow to read and write Domino data. The classic answers — XPages, DIIOP, a hand-rolled LotusScript web agent spitting JSON — all make the caller meet Domino on its terms. The Domino REST API (DRAPI, the KEEP project) flips it: a standard REST/JSON layer over your NSF that anything speaking HTTP can call. This is part one of a DRAPI series — what it is, how it differs from classic access, the three building blocks (scope/schema, JWT, OpenAPI/Swagger), and how to start.
2026.08.19 - Implementation Notes: DRAPI Login via Keycloak OIDC — Works on Domino 12.0.2, No Need to Wait for 14
Wiring DRAPI (Domino REST API) up to a modern IdP like Keycloak, Azure AD, or Okta is widely assumed to require Domino 14, since most of the public documentation centres on the 14-era OIDC story. In practice, DRAPI's oidc mode works on Domino 12.0.2 — no server upgrade required. This article is the implementation notebook from reproducing the full setup locally: picking among DRAPI's three OIDC modes (jwt / oidc / oidc-idpcat), debugging the three-layer auth architecture (identity / mapping / authorization), and the four traps that ate the most time — the biggest of which is providerUrl using localhost failing across machines because Java resolves IPv4 by default. Full step-by-step lives in the companion GitHub repo and Pages site; this article doesn't repeat the setup, it focuses on decisions and pitfalls.
2026.06.01 - Domino REST API: v1.1.7 Is the Current Latest — New Endpoints and Fixes
HCL Domino REST API's current latest release is v1.1.7 (shipped April 7, 2026), adding endpoints for calendar profiles, PIM unread state, and message updates, plus fixes for attachment download, Microsoft Entra ID auth, and meeting invitations.
2026.05.04 - Getting Started with DQL: Query Notes Documents with SQL-Style Syntax
Domino Query Language (DQL) gives you a near-SQL syntax for querying Notes documents directly, without designing a new view for every query shape. This is Part 1 of the 'DQL Trilogy': DQL's design rationale, writing your first query, calling DQL from LotusScript / Java / REST API, and a syntax cheat sheet. Query-writing pitfalls are in Part 2; shipping to production (catalog maintenance and permissions) is in Part 3.
2026.04.28 - HCL Domino REST API Quickstart Guide
This guide walks you through installing, configuring, and starting with the HCL Domino REST API, enabling access to Domino databases via a modern RESTful interface.
2026.04.28